The travis failure is due to the fact that the inline assembly uses thumb-2 instructions.

According to this page, we are supposed to use the thumb- targets, which makes sense to me.

I'm not sure why it works for gcc, but I suppose that gcc doesn't follow the same system.
I'm also confused as to how Parity successfully compiles despite the fact that is uses clang and a git version of ring (so no precompiled header).

Coverage remained the same at ?% when pulling 7b26072 on tomaka:clang-android-travis into ee13e73 on briansmith:master.

According to this page, we are supposed to use the thumb- targets, which makes sense to me.

Let's change this PR to use the thumb targets so the CI build step passes.

Let's change this PR to use the thumb targets so the CI build step passes.

Never mind,I don't think that's the right solution. I think I have a fix. Working on it.

I'm also confused as to how Parity successfully compiles despite the fact that is uses clang and [...]

I bet Parity is using a newer version of the NDK and/or clang or whatever and I bet that is the solution here. Any tips on how to get ring's CI to work more like Parity's?

Tests seem to pass on travis 🎉

Thanks! Merged.